Automated identification of service boundaries based on system focus optimization using distributed tracing data

ABSTRACT

A method for microservices architecture optimization is disclosed. The method includes receiving a first application request message at a gateway service, and generating a first client request message, by the gateway service, based on the first application request message. The first client request message may have a customized header comprising an identification of the gateway service. The method may include forwarding the first client request message from the gateway service to a first service of a plurality of services, and the first service updating the customized header of the first client request message to add an identification of the first service. The method includes generating, at the first service, a first client response message comprising the customized header, and generating, at the gateway service, a deployment scheme for a subset of services of the plurality of services based on the customized header of the first client response message. The deployment scheme may utilize an application specific criteria.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a Continuation Application of U.S. patentapplication Ser. No. 16/699,917, filed on Dec. 2, 2019, the contents ofwhich are incorporated herein in their entirety.

BACKGROUND

Software microservices architecture (SMA) is a variant ofservice-oriented architecture (SOA). In SOA, software service design,development, delivery, and deployment are based on modules that each maybe developed and deployed as independent systems. The modules in theSOA, therefore, offer the benefit of software agility because eachmodule may be developed, deployed, and operated independently from othermodules. Additionally, versioning and scaling of the modules based onchanged requirements may be addressed independently without affectingother modules. Thus, SMA is a collection of loosely coupled services.The loosely coupled services may use protocols that are lightweight.Since each service is a module capable of being developed and deployedindependently, the SMA may improve parallel development. Thus, itreduces time from lab to market.

The SMA often requires various services to communicate over a networkusing protocols such as hypertext transfer protocol (HTTP), etc.Therefore, the performance of the network and the microservices may beadversely affected due to network latency and message processing time incomparison with services implemented as a monolithic service process.Accordingly, if services were deployed without reviewing how variousservices interact with each other, a messaging overhead over the networkand network latency would severely degrade the network performance.Thus, it is important to know which microservices should be coupledtogether and which microservices should be decoupled to reduce themessaging overhead and network latency to increase performance of themicroservices and the network.

BRIEF DESCRIPTION OF THE DRAWINGS/FIGURES

The accompanying drawings are incorporated herein and form a part of thespecification.

FIG. 1 illustrates an exemplary microservices flow in softwaremicroservices architecture, in accordance with some embodiments.

FIG. 2 illustrates an exemplary microservices development flow, inaccordance with some embodiments.

FIG. 3 illustrates a flow chart of method steps for automaticidentification of service boundaries based on system optimization usingdistributed tracing data, in accordance with some embodiments.

FIG. 4 illustrates an exemplary computer system, in accordance with someembodiments.

In the drawings, like reference numbers generally indicate identical orsimilar elements. Additionally, generally, the left-most digit(s) of areference number identifies the drawing in which the reference numberfirst appears.

DETAILED DESCRIPTION

Provided herein are a method, a system, and a computer program productembodiments, and/or combinations and sub-combinations thereof, forautomated identification of service boundaries of various services of asoftware microservices architecture (SMA). In particularly, thisdisclosure is related to identification of boundaries of services of SMAbased on system focus optimization using distributed tracing data.

Various embodiments of this disclosure will now be discussed withrespect to the corresponding figures.

FIG. 1 illustrates an exemplary microservices flow in softwaremicroservices architecture, in accordance with some embodiments. Shownin FIG. 1 is exemplary software microservices architecture (SMA) 100that may include microservices 102 a, 102 b, 102 c, and 102 d. The SMA100 shown in FIG. 1 is exemplary and does not limit the number ofmicroservices. Each microservice of the microservices 102 a-102 d may beassigned a service-id. The service-id identifies the microservice in theSMA. The microservices 102 a, 102 b, 102 c, and 102 d may be assignedservice-ids Service 126 a, Service 126 b, Service 126 c, and Service 126d respectively. The service-ids 126 a-126 d may be numeric oralphanumeric.

In SMA, a microservice is a module implementing business functionalitywith interfaces to communicate with other microservices as well asentities outside the SMA network. The microservices are loosely coupledservices, with each microservice providing or implementing a differentfunctionality. Therefore, a first microservice may be a client of asecond microservice where the first microservice is provided a serviceby the second microservice. In one example, a second microservice mayprovide database related services. Accordingly, any microservice thatmay require access to the database would be a client of the secondmicroservice. Accordingly, a call flow, i.e., a flow of messagesexchanged between a client sending a request message to a microserviceof the SMA and receiving a response from the microservice of the SMAwould also include messages exchanged between the microservices of theSMA. Therefore, each microservice in a call flow may be identified basedon the service-id assigned to the microservice, when the messagesexchanged between the microservices include service-id information inthe messages.

In SMA, microservices 102 a-102 d may be implemented using differentprogramming languages and may use different infrastructure. Themicroservices 102 a-102 d may use various mechanisms or protocols tocommunicate with each other. By way of non-limiting example, themicroservices may use hypertext transfer (HTTP) protocol. A secureversion of the HTTP protocol (HTTPS) may also be used. The microservicesmay use the HTTP/HTTPS protocol to exchange web services messages using,for example, service oriented architecture protocol (SOAP),representational state transfer (REST), etc. Accordingly, messagesexchanged between the microservices using the SOAP/REST over theHTTP/HTTPS protocol may have various headers that may identify a sourceendpoint and a destination endpoint, a user agent, timestamp, a sourceand a destination IP address or a fully qualified domain name (FQDN)etc.

In some embodiments, in SMA, many microservices together provide arequired service or functionality. Therefore, the microservicesproviding the required service or functionality may be either groupedtogether or distributed to achieve the best performance. In someembodiments, the microservices are called together. If the client deviceis required to make multiple requests to collect complete informationfrom the microservices, it may result in inefficient and slow networkperformance. This is because making multiple network round trips is moretime consuming and error prone than making a single request. Further,aggregating the results from multiple service requests requiresadditional time and computing resources. Accordingly, if themicroservices share common entities, the microservices may be groupedtogether in order to provide better bulk processing capabilities.Similarly, if a response time to a request from a client for a singlemicroservice varies drastically based on the request or endpointpattern, the microservice should be split to improve response time.Thus, the microservices may be grouped together or distributed and maybe installed on one or more servers. In other words, not allmicroservices required for the service or functionality may be requiredto be installed or deployed on a single server. The microservices may bedistributed to achieve best performance.

In some embodiments, in SMA, one or more microservices may be designatedas a gateway microservice. The gateway microservice may provide one ormore endpoints to which a client device may send a request message toreceive a service provided by the microservices. The one or moreendpoints then may process the received request message to forward oneor more messages to other microservices. The one or more messages to theother microservices may be generated by the gateway microservice basedon the received request message from the client device.

By way of a non-limiting example, the client device may be a smartphone, a mobile phone, a laptop, a tablet, a personal computer, adesktop, a server, etc. The microservices may be installed, for example,on a web server or an application server. The web server or theapplication server may be an Apache Tomcat server, a WebLogic server,etc.

As shown in FIG. 1, an application request message 110 may be originatedfrom a client device (not shown in FIG. 1) and received at themicroservice service 102 a. The microservice 102 a may be a gatewayservice and may provide one or more endpoints to receive applicationrequest messages from client devices. A gateway service is amicroservice between client devices sending application request messagesto the microservices of the SMA. Application request messages from theclient devices to the gateway service are received via a channel, whichmay have two or more endpoints. An endpoint is thus controlled by themicroservice to which it is connected. Characteristics of the endpointmay include schema of the messages being received or sent through theendpoint, and an address such as an IP address used to receive or sendmessages.

In some embodiments, the application request message 110 may be a webservice message according to Service Oriented Architecture Protocol(SOAP), or Representational State Transfer (REST). The applicationrequest message may also use hypertext transfer protocol (HTTP) orhypertext transfer protocol secure (HTTPS). Application request message110 using the HTTP, HTTPS, SOAP, and/or REST may include various messageheaders, for example, Host, Content-Type, Content-Length, etc.Accordingly, the application request message 110 may include variousheaders. Additionally, new headers may also be added to the messagesthat are being exchanged between various microservices and with theclient devices. An example of a request message and a response messagewith various headers, including the TraceId header, is shown below.

A portion of an exemplary HTTP request message is shown below. A newcustomized header, TraceId may be added to the message while sending theHTTP request message to other microservices.

GET/doc/account.html HTTP/1.1Host: www.mytestservice.comAccept: image/gif, image/jpeg, */*Accept-language: en-us

User-Agent: Mozilla/4.0 Content-Length: 40 TraceId:ServiceId1,ServiceId2

A portion of an exemplary HTTP response message is shown below. A newcustomized header, TraceId may be added to the message while sending theHTTP response message to other microservices and/or the client devices.

HTTP/1.1 200 OK Server: Apache/1.3.29 (Win32)

Accept-Ranges: bytes

Content-Length: 50 TraceId: ServiceId1,ServiceId2

In some embodiments, the application request message 110 from the clientdevice may be received at one endpoint of the one or more endpoints ofthe microservice service 102 a. The application request message 110 mayinclude various headers as described above. In addition to variousheaders, the application request message 110 may include other dataidentifying a service requested by the client device from the SMA 100.The gateway service, i.e., the microservice service 102 a, may processthe application request message 110 and identify that microservice 102 bmay be invoked. The microservice service 102 a therefore may buildanother request message 112 based on the application request message110. The microservice service 102 a may add a new customized header to aclient request message 112.

In some embodiments, for example, a new customized header named TraceIdmay be added to client request message 112. The TraceId header's valuemay be set to an identification of the microservice that processed theapplication request message and/or the client request message.Similarly, microservices may add the TraceId header while building aresponse message to the application request message and/or clientrequest message with the value of the TraceId header set to theidentification of the microservice. Accordingly, the microservice 102 amay add the TraceId header to the client request message 112 with thevalue set to an identification of the microservice 102 a 126 a toindicate that microservice 102 a is required for the service orfunctionality requested by the client device.

In some embodiments, when the client request message 112 received by themicroservice 102 b, the microservice service 102 b may process theclient request message 112. The microservice 102 c may be a serviceproviding database related services. Accordingly, while processing theclient request message 112, if the microservice 102 b requires databaserelated services, the microservice 102 b may invoke the microservice 102c. Accordingly, the microservice 102 b may build a client requestmessage 114 to send to the microservice 102 c. The client requestmessage 114 may therefore be based on the client request message 112.

For example, the microservice 102 b may include TraceId header 112 awith its value from the client request message 112 in the client requestmessage 114, and also update the value of the TraceId header in theclient request message 114 to further include identification of themicroservice 102 b 126 b. Accordingly, the TraceId header 114 a may havea value set to “ServiceId1,ServiceId2” in the client request message114. In some embodiments, for example, the identification of themicroservice 102 a 126 a and the identification of the microservice 102b 126 b may be comma separated. However, other separator such as “;” or“|” or white-space, or like of it may also be used, e.g.,“ServiceId1;ServiceId2” or “ServiceId1|ServiceId2” or “ServiceId1ServiceId2” or like of it.

The microservice 102 c may process the client request message 114 andreturn a client response message 116 to the microservice 102 b. Themicroservice 102 c may include TraceId header from the client requestmessage 114 in the response message 116. The TraceId header 116 a in theclient response message 116 may therefore include the identification ofthe microservice 102 a 126 a and the identification of the microservice102 b 126 b. The microservice 102 c may further include theidentification of the microservice 102 c 126 c in the client responsemessage 116.

The client response message 116 when received by the microservice 102 b,the microservice 102 b may determine that no more microservice isrequired to be invoked. Accordingly, the microservice 102 b may buildthe client response message 122. The microservice 102 b may extractvalue of the TraceId header 116 a from the client response message 116,which may include the identification of the microservices 102 a, 102 b,and 102 c, which are 126 a, 126 b, and 126 c. The microservice 102 b maybuild the client response message 122 that may include the TraceIdheader with its (not shown in FIG. 1) set to the identification of themicroservices 102 a, 102 b, 102 c, which are 126 a, 126 b, and 126 c.Because the identification of the microservice 102 b is already presentin the value of the TraceId header, the identification of themicroservice 102 b may not be added again. The client response message122 may then be forwarded to the microservice service 102 a.

Based on the value of the TraceId header of the client response message122, the microservice 102 a may determine that for the particularservice or functionality requested corresponding to the applicationrequest message 110, microservices 102 a, 102 b, and 102 c are requiredservices.

In some embodiments, for example, the microservice 102 b may determine,upon receipt of the client response message 116, that the microservice102 d is required to be invoked in accordance with a business logic orfunctionality provided by the microservice 102 b. Accordingly, themicroservice 102 b may build a client request message 118 having aTraceId header 118 a with its value set to the value of the TraceIdheader from the client response message 116. Because the identificationof the microservice 102 b is already present in the value of the TraceIdheader, the identification of the microservice 102 b 126 b may not beadded again to the TraceId header 118 a. The microservice 102 d maybuild a client response message 120 similar to the microservice 102 c.Therefore, similar to the microservice 102 c, the microservice 102 d mayinclude TraceId header 120 a that may include the identification of themicroservices 102 a, 102 b, 102 c, and 102 d, which are 126 a, 126 b,126 c, and 126 d. When the client response message 120 is received bythe microservice 102 b, based on the business logic or functionalityprovided by the microservice 102 b, the microservice 102 b may determinethat no other microservice is further required to be invoked.Accordingly, the microservice 102 b may build the client responsemessage 122 with the TraceId header 122 a with its value set to theidentifications of the 102 a, 102 b, 102 c, and 102 d, which are 126 a,126 b, 126 c, and 126 d. The microservice 102 a may therefore determinethat for the particular service or functionality requested in theapplication request message 110 may requires services from themicroservices 102 a, 102 b, 102 c, and 102 d. The microservice 102 a maythen build the application response message 124 with TraceId header 124a with its value set to the identifications 126 a, 126 b, 126 c, and 126d.

The microservice service 102 a may determine the microservices requiredto be invoked for each application client request message, which may ormay not be similar to the application request message 110. In otherwords, each client request message similar to the application requestmessage 110 may differ in the values set for various headers of theapplication request message. Accordingly, the microservices which arerequired to provide services according to the application requestmessages may be deployed together and/or deployed on the same server,which may result in reduced latency and improved performance of thenetwork and the SMA.

In some embodiments, for example, the microservice 102 a may recordmessages sent to other microservices and received from the othermicroservices for later analysis to generate a deployment scheme. Themessages may be recorded in a database or a log file. The recordedmessages may be analyzed to generate the deployment scheme. Thedeployment scheme may be dependent on application specific criteriadiscussed below.

FIG. 2 illustrates an exemplary microservices development flow, inaccordance with some embodiments. As described earlier, in SMA,microservices are loosely coupled modules that together provide serviceor functionality. Since microservices are modules, each module may bedeveloped and deployed independently. Further, each module may bedeveloped for a specific functionality; the modules may be developedfaster and deployed faster because each module supports a small piece ofthe functionality provided by the modules as a collection, which is asubstantial advantage of the SMA. Thus, modular or microservices designin SMA may be domain driven, and technology stack agnostic as shown inFIG. 2. Particularly, by way of non-limiting example, four teams, a teamA 202 a, a team B 202 b, a team C 202 c, and a team D 202 d are shown inFIG. 2. The team A 202 a, the team B 202 b, the team C 202 c, and theteam D 202 d may each be developing a microservice. For example, eachteam 202 a, 202 b, 202 c, and 202 d may be developing one of themicroservices from 102 a, 102 b, 102 c, and 102 d. Each team may includedevelopers for developing the microservices using different technology,programming language, and/or a framework. By way of non-limitingexample, the team A 202 a may have a sub-team 204 a developingmicroservices using the C programming language, a sub-team 204 b usingthe Java Script programming language, and sub-teams 204 c and 204 dusing the Java programming language. Similarly, the team B 202 b mayhave a sub-team 204 e developing microservices using Java Script, asub-team 204 f using Scala and a sub-team 204 g using Python. The team C202 c may have sub-teams 204 h using the Scala, 204 i and 204 j usingthe Java programming language, and 204 k using the Java Scriptprogramming language. The team D 202 d may have sub-teams 204 l, 204 m,and 2004 n using the Java programming language, Scala, and Scalarespectively. Further, in some embodiments, for example, as shown inFIG. 2, the team C 202 c may depend on software delivery and/or aninterface from the team A 202 a, and the team D 202 d may depend onsoftware delivery and/or an interface from the teams A 202 a, B 202 b,and C 202 c. Since microservices are modules, each module ormicroservice may be scaled up/down independent of the othermicroservices, and may also be delivered and deployed independent of theother microservices.

FIG. 3 illustrates a flow chart of method steps for automaticidentification of service boundaries based on system optimization usingdistributed tracing data, in accordance with some embodiments. At step302, a first application request message may be received by a gatewayservice. For example, the microservice 102 a may be the gateway serviceas described above. The first application request message may be similarto the application request message 110 described above. The firstapplication request message being similar to the application requestmessage 110 means that the headers and message content may be differentand the value of the headers may be set according to the firstapplication request message received at an endpoint of the gatewayservice. As described above, the endpoint is a channel via which themessages are communicated or exchanged between the client and themicroservice.

In some embodiments, at step 304, upon receipt of the first applicationrequest message at the endpoint of the gateway service, a first clientrequest message based on the first application request message may begenerated. The gateway service processes the first application requestmessage according to the business logic corresponding to the requestedservice or functionality by the first application request message. Uponprocessing the first application request message, the gateway servicemay determine that the requested service of functionality requiresinvocation of service from other microservice(s). Accordingly, thegateway service may generate the first client request message from thefirst application request message. To identify which other microservicesmay be invoked corresponding to the first application request message,the gateway service may add a new customized header in the first clientrequest message.

In some embodiments, for example, the new customized header may be namedTraceId. The TraceId header may be set to a value of an identificationof the gateway service. Accordingly, the TraceId header may indicatewhich microservices processed requests and responses corresponding tothe first application request message. The first application requestmessage and the first client request message may further be associatedbased on a unique identification. The first application request messagemay include a universal unique identifier (UUID) header. The value ofthe UUID header may uniquely identify the first application requestmessage among plurality of similar other messages received at theendpoint of the gateway service. Accordingly, all request messages andresponse messages generated by various microservices may include theUUID header with the value set to the value of the UUID header in thefirst application request message.

In some embodiments, each microservices may record the request andresponse messages that were received and sent respectively. The messagesmay be recorded in a text file or in a database. The text file may be alog file. Accordingly, the messages may be recorded in the log file inthe database, which may be local to the microservice or centralized. Ifthe messages are recorded at a centralized database or logging system,the microservice may communicate to the centralized database or loggingsystem over network interface using, for example, TCP/IP, UDP, and/orapplication programming interface (API) messages. By way of anon-limiting example, the microservice may record the endpoint of themicroservice at which the message is received, a source address, anincoming timestamp corresponding to receipt of the request, an outgoingtimestamp corresponding to another request/response message, the UUIDheader value, the TraceId header value, etc.

In some embodiments, at step 306, the gateway service may forward thefirst client request message to a first service of the plurality ofservices. The first service of the plurality of services may be themicroservice service 102 b, and the first client request message may bethe client request message 112. As described above, the client requestmessage 112 may include the TraceId header with its value set to theidentification of the gateway service.

In some embodiments, at step 308, as described above, the first servicemay process the received first client request message 112. Themicroservice 102 b may determine that no other microservice is requiredto be invoked based on processing of the first client request message112. The microservice 102 b then may update the TraceId header value toadd identification of the microservice 102 b, and may generate a firstclient response message 122 at step 310. The microservice 102 b mayinclude the updated TraceId header in the first client response message122. The first client response message 122 may then be sent by themicroservice 102 b to the gateway service 102 a. The microservice 102 bmay record the received first client request message 112 and the firstclient response message 122 sent from the microservice 102 b to thegateway service 102 a. The gateway service may receive the first clientresponse, and as described above may record the received first clientresponse.

In some embodiments, at step 312, the gateway service 102 a may generatea deployment scheme for a subset of services of the plurality ofservices based on the TraceId header value of the first client responsemessage 122. As described above, the TraceId header value in the firstclient response may indicate all the microservices invoked in responseto the receipt of the first application request message 110. Thedeployment scheme may be generated based on application specificcriteria as described below.

In some embodiments, the application specific criteria may recommenddetermining a set of services, which are common to a plurality ofapplication request messages to be deployed together. By way ofnon-limiting example, if the plurality of application request messagescomprise messages of a first application request message type and asecond application request message type, the microservices which arecommonly invoked by the first application request message type and thesecond application request message type may be deployed together. Themessage type may be associated with a service or functionality.Therefore, messages from various client devices requesting the serviceor the functionality may generate messages that may have similar messagestructure, but the value assigned to the headers may be different basedon the client device requesting the service or the functionality.

In some embodiments, the application specific criteria may recommenddetermining a set of microservices being called together correspondingto the first application request message to be deployed together.

In yet another embodiment, the application specific criteria mayrecommend determining a message load over a configurable time period fora set of services, and generating a recommendation that the set ofservice be deployed according to the message load over the configurabletime period. If the particular set of services is being invoked for allthe messages received at endpoints of the gateway service, and which forexample consumes substantial processing power, deploying such servicewith other services may adversely affect performance of the otherservices. Accordingly, specification of a server, i.e., CPU, memory, andother specification, may be considered in generating a recommendation ofhow the services may be deployed.

As described above, the endpoint is a channel via which a microservicemay exchange messages with the client devices and/or othermicroservices. Accordingly, the microservice may disclose a plurality ofendpoints at which requests from the client devices and othermicroservices may be received. If it may be identified by the gatewayservice, based on the analysis of the recorded request messages andresponse by various microservices, at least one endpoint of theplurality of endpoints does not share common resource with otherendpoints, the deployment scheme may be generated which may recommendthat the at least one endpoint be decoupled from the other endpoints ofthe plurality of endpoints. The application specific criteria thus mayinclude updating the set of services together and/or deploying the setof service together.

FIG. 4 illustrates an example of a computer system, in accordance withsome embodiments.

Various embodiments may be implemented, for example, using one or morewell-known computer systems, such as a computer system 400 as shown inFIG. 4. One or more computer systems 400 may be used, for example, toimplement any of the embodiments discussed herein, as well ascombinations and sub-combinations thereof.

The computer system 400 may include one or more processors (also calledcentral processing units, or CPUs), such as a processor 404. Theprocessor 404 may be connected to a communication infrastructure or bus406.

The computer system 400 may also include user input/output device(s)403, such as monitors, keyboards, pointing devices, etc., which maycommunicate with communication infrastructure 406 through userinput/output interface(s) 402.

One or more of processors 404 may be a graphics processing unit (GPU).In an embodiment, a GPU may be a processor that is a specializedelectronic circuit designed to process mathematically intensiveapplications. The GPU may have a parallel structure that is efficientfor parallel processing of large blocks of data, such as mathematicallyintensive data common to computer graphics applications, images, videos,etc.

The computer system 400 may also include a main or primary memory 408,such as random access memory (RAM). Main memory 408 may include one ormore levels of cache. Main memory 408 may have stored therein controllogic (i.e., computer software) and/or data.

The computer system 400 may also include one or more secondary storagedevices or memory 410. The secondary memory 410 may include, forexample, a hard disk drive 412 and/or a removable storage device ordrive 414. The removable storage drive 414 may be a floppy disk drive, amagnetic tape drive, a compact disk drive, an optical storage device,tape backup device, and/or any other storage device/drive.

The removable storage drive 414 may interact with a removable storageunit 418. The removable storage unit 418 may include a computer usableor readable storage device having stored thereon computer software(control logic) and/or data. The removable storage unit 418 may be afloppy disk, magnetic tape, compact disk, DVD, optical storage disk,and/any other computer data storage device. The removable storage drive414 may read from and/or write to removable storage unit 418.

The secondary memory 410 may include other means, devices, components,instrumentalities or other approaches for allowing computer programsand/or other instructions and/or data to be accessed by the computersystem 400. Such means, devices, components, instrumentalities or otherapproaches may include, for example, a removable storage unit 422 and aninterface 420. Examples of the removable storage unit 422 and theinterface 420 may include a program cartridge and cartridge interface(such as that found in video game devices), a removable memory chip(such as an EPROM or PROM) and associated socket, a memory stick and USBport, a memory card and associated memory card slot, and/or any otherremovable storage unit and associated interface.

The computer system 400 may further include a communication or networkinterface 424. The communication interface 424 may enable the computersystem 400 to communicate and interact with any combination of externaldevices, external networks, external entities, etc. (individually andcollectively referenced by reference number 428). For example, thecommunication interface 424 may allow the computer system 400 tocommunicate with the external or remote devices 428 over communicationspath 426, which may be wired and/or wireless (or a combination thereof),and which may include any combination of LANs, WANs, the Internet, etc.Control logic and/or data may be transmitted to and from the computersystem 400 via the communication path 426.

The computer system 400 may also be any of a personal digital assistant(PDA), desktop workstation, laptop or notebook computer, netbook,tablet, smart phone, smart watch or other wearable, appliance, part ofthe Internet-of-Things, and/or embedded system, to name a fewnon-limiting examples, or any combination thereof.

The computer system 400 may be a client or server, accessing or hostingany applications and/or data through any delivery paradigm, includingbut not limited to remote or distributed cloud computing solutions;local or on-premises software (“on-premise” cloud-based solutions); “asa service” models (e.g., content as a service (CaaS), digital content asa service (DCaaS), software as a service (SaaS), managed software as aservice (MSaaS), platform as a service (PaaS), desktop as a service(DaaS), framework as a service (FaaS), backend as a service (BaaS),mobile backend as a service (MBaaS), infrastructure as a service (IaaS),etc.); and/or a hybrid model including any combination of the foregoingexamples or other services or delivery paradigms.

Any applicable data structures, file formats, and schemas in thecomputer system 400 may be derived from standards including but notlimited to JavaScript Object Notation (JSON), Extensible Markup Language(XML), Yet Another Markup Language (YAML), Extensible Hypertext MarkupLanguage (XHTML), Wireless Markup Language (WML), MessagePack, XML UserInterface Language (XUL), or any other functionally similarrepresentations alone or in combination. Alternatively, proprietary datastructures, formats or schemas may be used, either exclusively or incombination with known or open standards.

In some embodiments, a tangible, non-transitory apparatus or article ofmanufacture comprising a tangible, non-transitory computer useable orreadable medium having control logic (software) stored thereon may alsobe referred to herein as a computer program product or program storagedevice. This includes, but is not limited to, the computer system 400,the main memory 408, the secondary memory 410, and the removable storageunits 418 and 422, as well as tangible articles of manufacture embodyingany combination of the foregoing. Such control logic, when executed byone or more data processing devices (such as the computer system 400),may cause such data processing devices to operate as described herein.

Based on the teachings contained in this disclosure, it will be apparentto persons skilled in the relevant art(s) how to make and useembodiments of this disclosure using data processing devices, computersystems and/or computer architectures other than that shown in FIG. 4.In particular, embodiments can operate with software, hardware, and/oroperating system implementations other than those described herein.

The present invention has been described above with the aid offunctional building blocks illustrating the implementation of specifiedfunctions and relationships thereof. The boundaries of these functionalbuilding blocks have been arbitrarily defined herein for the convenienceof the description. Alternate boundaries can be defined so long as thespecified functions and relationships thereof are appropriatelyperformed.

The foregoing description of the specific embodiments will so fullyreveal the general nature of the invention that others can, by applyingknowledge within the skill of the art, readily modify and/or adapt forvarious applications such specific embodiments, without undueexperimentation, without departing from the general concept of thepresent invention. Therefore, such adaptations and modifications areintended to be within the meaning and range of equivalents of thedisclosed embodiments, based on the teaching and guidance presentedherein. It is to be understood that the phraseology or terminologyherein is for the purpose of description and not of limitation, suchthat the terminology or phraseology of the present specification is tobe interpreted by the skilled artisan in light of the teachings andguidance.

The breadth and scope of the present invention should not be limited byany of the above-described exemplary embodiments, but should be definedonly in accordance with the following claims and their equivalents.

The claims in the instant application are different than those of theparent application or other related applications. The Applicanttherefore rescinds any disclaimer of claim scope made in the parentapplication or any predecessor application in relation to the instantapplication. The Examiner is therefore advised that any such previousdisclaimer and the cited references that it was made to avoid, may needto be revisited. Further, the Examiner is also reminded that anydisclaimer made in the instant application should not be read into oragainst the parent application.

What is claimed is:
 1. A method for microservices architectureoptimization, the method comprising: receiving, by a gateway service, aplurality of application request messages, each application requestmessage having a type; generating, by the gateway service, a clientrequest message for each of the plurality of the application requestmessages; forwarding, by the gateway service, each of the client requestmessages to a respective service of a plurality of services associatedwith each of the client request messages; identifying, by the gatewayservice, shared characteristics of the plurality of services based on avalue of a header added in each of the client request messages; andgenerating, at the gateway service, a scheme for deploying the pluralityof services together based on the identified shared characteristics ofthe plurality of services.
 2. The method of claim 1, wherein generatingthe scheme for deploying the plurality of services together comprises:determining the plurality of services are commonly invoked by a firstapplication request message having a first type and a second applicationrequest message having a second type, wherein the first type isdifferent from the second type.
 3. The method of claim 1, whereingenerating the scheme for deploying the plurality of service togethercomprises: determining a message load corresponding to a first type ofan application request message of the plurality of application requestmessages and a second type of an application request message of theplurality of application request messages.
 4. The method of claim 3,wherein the message load corresponding to the first type and the secondtype is measured over a configurable time period.
 5. The method of claim1, further comprising: identifying at least one endpoint of a pluralityof endpoints corresponding to a service of the plurality of servicesthat shares no common resource with other endpoints of the plurality ofendpoints; and generating, at the gateway service, a recommendation thatthe at least one endpoint is decoupled from the other endpoints of theplurality of endpoints.
 6. The method of claim 1, wherein generating thescheme for deploying the plurality of service together comprises:generating a recommendation based on specification of a server, thespecification including requirements of at least one of a centralprocessing unit (CPU), and a memory.
 7. The method of claim 1, wherein amessage structure of a first application request message of theplurality of application request messages is different from a messagestructure of a second application request message of the plurality ofapplication request messages.
 8. A system, comprising: a memory forstoring operations; and one or more processors, communicatively coupledto the memory, configured to perform the operations comprising:receiving, by a gateway service, a plurality of application requestmessages, each application request message having a type; generating, bythe gateway service, a client request message for each of the pluralityof the application request messages; forwarding, by the gateway service,each of the client request messages to a respective service of aplurality of services associated with each of the client requestmessages; identifying, by the gateway service, shared characteristics ofthe plurality of services based on a value of a header added in each ofthe client request messages; and generating, at the gateway service, ascheme for deploying the plurality of services together based on theidentified shared characteristics of the plurality of services.
 9. Thesystem of claim 8, wherein for generating the scheme for deploying theplurality of service together, the operations further comprise:determining the plurality of services are commonly invoked by a firstapplication request message having a first type and a second applicationrequest message having a second type, wherein the first type isdifferent from the second type.
 10. The system of claim 8, wherein forgenerating the scheme for deploying the plurality of service together,the operations further comprise: determining a message loadcorresponding to a first type of an application request message of theplurality of application request messages and a second type of anapplication request message of the plurality of application requestmessages.
 11. The system of claim 10, wherein the message loadcorresponding to the first type and the second type is measured over aconfigurable time period.
 12. The system of claim 8, wherein theoperations further comprise: identifying at least one endpoint of aplurality of endpoints corresponding to a service of the plurality ofservices that shares no common resource with other endpoints of theplurality of endpoints; and generating a recommendation that the atleast one endpoint is decoupled from the other endpoints of theplurality of endpoints.
 13. The system of claim 8, wherein forgenerating the scheme for deploying the plurality of service together,the operations further comprise: generating a recommendation based onspecification of a server, the specification including requirements ofat least one of a central processing unit (CPU), and a memory.
 14. Thesystem of claim 8, wherein a message structure of a first applicationrequest message of the plurality of application request messages isdifferent from a message structure of a second application requestmessage of the plurality of application request messages.
 15. Anon-transitory, tangible computer-readable device having instructionsstored thereon that, when executed by at least one computing device,causes the at least one computing device to perform operations,comprising: receiving, by a gateway service, a plurality of applicationrequest messages, each application request message having a type;generating, by the gateway service, a client request message for each ofthe plurality of the application request messages; forwarding, by thegateway service, each of the client request messages to a respectiveservice of a plurality of services associated with each of the clientrequest messages; identifying, by the gateway service, sharedcharacteristics of the plurality of services based on a value of aheader added in each of the client request messages; and generating, atthe gateway service, a scheme for deploying the plurality of servicestogether based on the identified shared characteristics of the pluralityof services.
 16. The non-transitory, tangible computer-readable deviceof claim 15, wherein for generating the scheme for deploying theplurality of service together, the operations further comprise:determining the plurality of services are commonly invoked by a firstapplication request message having a first type and a second applicationrequest message having a second type, wherein the first type isdifferent from the second type.
 17. The non-transitory, tangiblecomputer-readable device of claim 15, wherein for generating the schemefor deploying the plurality of service together, the operations furthercomprise: determining a message load corresponding to a first type of anapplication request message of the plurality of application requestmessages and a second type of an application request message of theplurality of application request messages.
 18. The non-transitory,tangible computer-readable device of claim 17, wherein the message loadcorresponding to the first type and the second type is measured over aconfigurable time period.
 19. The non-transitory, tangiblecomputer-readable device of claim 15, wherein the operations furthercomprise: identifying at least one endpoint of a plurality of endpointscorresponding to a service of the plurality of services that shares nocommon resource with other endpoints of the plurality of endpoints; andgenerating a recommendation that the at least one endpoint is decoupledfrom the other endpoints of the plurality of endpoints.
 20. Thenon-transitory, tangible computer-readable device of claim 15, whereinfor generating the scheme for deploying the plurality of servicetogether, the operations further comprise: generating a recommendationbased on specification of a server, the specification includingrequirements of at least one of a central processing unit (CPU), and amemory.